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ABSTRACT 

On  20  January  1999,  under  the  leadership  of 
the  Navy’s  Battle  Force  Systems  Engineer 
(SEA05),  an  Alliance  of  Naval  Sea  Systems 
Command,  Space  and  Warfare  Systems 
Command,  and  Naval  Air  Systems 
Command  field  activities  headed  by  Naval 
Surface  Warfare  Center  (NSWC),  Dahlgren 
Division,  stood  up  the  Navy  Distributed 
Engineering  Plant  (DEP).  The  Navy  DEP 
leveraged  the  Leading  Edge  Services  (LES- 
98)  and  Defense  Research  and  Engineering 
Network  (DREN)  Asynchronous  Transfer 
Mode  (ATM)  Networks  to  connect 
geographically  dispersed  Navy  Design  and 
Development  Activities,  Software  Support 
Activities  (SSA),  Test  and  Evaluation 
(T&E)  Facilities,  and  Training  Centers. 
Integrating,  at  the  laboratory  level,  actual 
fleet  hardware  and  tactical  computer 
program  loads  in  a  distributed  configuration 
provided  the  Navy  a  controlled,  repeatable 
environment  in  which  to,  for  the  first  time, 
fault  isolate  and  verily  resolution  of  Battle 
Group  interoperability  problems,  and  system 
engineer  at  the  ‘system-of-system’  and 
‘family-of-systems’  level.  A  resounding 
success  from  ‘stand-up’,  the  Navy  DEP  was 
quickly  recognized  by  the  Department  of 
Defense  as  an  engineering  tool  to  solve  Joint 
interoperability  problems. 

INTRODUCTION 

Warfighting  capability  being  developed  and 
deployed  transcends  traditional  system  and 
ship  boundaries.  Technology  to  provide  this 
warfighting  capability  allowed  increasingly 


complex  systems  to  be  developed.  However, 
Navy  and  Joint  combat  and  BMC4I  systems 
have,  generally,  been  designed  and  procured 
as  “stand  alone”  systems  or  elements.  A 
disciplined  force  level  systems 
engineering  process  has  not  been  required 
nor  employed.  Tactical  data  Link  operational 
specifications,  such  as  OPSPEC  411  and 
516,  attempt  to  ensure  that  systems  are 
interfaced  properly  over  Link  1 1  and  16  and 
are  interoperable. 

Developmental  and  operational  test  and 
evaluation  has  been  conducted  at  the  system 
or  platform  level.  For  vehicles,  such  as 
combatants,  carriers,  and  aircraft,  the 
combat  systems  and  Battle 
Management/Command  and  Control, 
Communications,  Computers  and 
Intelligence  (BM/C4I)  systems  have  been 
well  integrated  and  tested  "within  the 
lifelines"  of  the  platform  at  engineering 
facilities  such  as  the  Integrated  Combat 
System  Test  Facility  (ICSTF),  San  Diego 
California  or  Surface  Combat  System  Center 
(SCSC),  Wallops  Island  Virginia.  The 
capability  to  design,  engineer,  and  test  for 
interoperability  at  a  battle  group  or  family 
of  systems  level  has  not  existed. 

Additionally,  no  overarching  force  or 
family  of  systems  level  interoperability 
requirements  exist.  Interoperability 
standards  are  insufficient  to  ensure 
interoperability  because  of  minimum 
implementation  and  imprecision  in 
specification  of  critical  functions. 
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Battle  Group/Battle  Force  (BG/BF)  warfare 
system  engineering  and  design  has  not  been 
performed  on  currently  fielded  systems.  The 
first  time  system  of  systems  could  be  tested 
together  was  during  Fleet  exercises,  BG 
work  ups,  or  Fleet  Operational  Test  and 
Evaluation  (FOT&E)  events  utilizing 
operational  forces. 

This  caused  a  crisis  when  the  complexity  of 
systems,  the  lack  of  successful  integration, 
and  failure  of  critical  systems  resulted  in  an 
incoherent  tactical  picture  for  battle  group 
operators,  and  the  Navy  could  not  deploy 
two  combatants.  The  two  ships  did  not 
provided  reliable  interoperable  warfighting 
capability.  Interoperability  problems  were 
experienced  by  operational  forces  —  Sailors 
and  Marines  —  as  they  performed  critical 
operational  training  (COMTUEX,  JTFEX) 
and  during  deployment. 

The  operational  at-sea  environment  could 
not  provide  a  disciplined  repeatable 
engineering  environment  for  (1)  isolating 
and  root  causing  problems,  and  (2) 
engineering  solutions  to  interoperability 
problems  at  the  family-of-sy stems  level. 
Both  Navy  and  Joint  combat  and  BM/C4I 
systems  experienced  interoperability 
problems  that  degraded  the  warfighting 
capability  of  our  deploying  or  deployed 
forces.  This  was  evidenced  by  unit  reporting 
responsibility  conflicts,  position  errors,  dual 
tracks.  Identification  Friend-or-Foe  (IFF) 
conflicts,  and  track  and  track  number  update 
errors.  The  warfighting  impact  was  a 
confused  tactical  picture,  and  weapons  and 
sensors  that  were  not  interoperable  and  that 
were  not  being  used  to  effective  ranges. 

In  February  1998,  Admiral  Reason, 
Commander  in  Chief,  Atlantic  Fleet,  opined 
in  a  message  to  the  Chief  of  Naval 
Operations  (CNO)  that  ''despite  admirable 
efforts  ...  the  acquisition  community  failed 
to  deliver  integrated  warjighting  capability 
to  our  Battle  Groups”  (CLF  Msg  061415Z 
Feb  98).  In  response,  the  CNO  assigned 
Commander,  Naval  Sea  Systems  Command 
"central  responsibility  to  address 


BM/C4I/Combat  Systems  interoperability 
problems  within  the  Systems 
Commands/Program  Executive  Offices 
(SYSCOMs/PEOs),  and  to  coordinate 
resolution  with  the  fleet  ”(CNO  Msg 
021648Z  May  1998). 

To  design,  engineer,  and  test  for 
interoperability  at  the  Battle  Group/Battle 
Force  or  family-of-system  level,  the 
engineering  and  acquisition  communities 
needed  a  new  and  pioneering  capability  -  a 
Distributed  Engineering  Plant  (DEP).  This 
DEP  capability  must  (1)  move 
interoperability  problem  discovery  ashore, 
(2)  provide  a  repeatable  controlled 
environment  for  evaluation  of  battle  group 
interoperability  problems,  (3)  contribute  to 
the  ability  to  conduct  system  level  “fault 
isolation”  of  problems,  and  (4)  enable 
validation  of  operational  tactics,  techniques, 
and  procedures  [work  arounds]  prior  to 
going  to  sea.  The  austere  times  demand 
innovation  to  establish  and  deliver  a  DEP 
capability. 


DISTRIBUTED 

ENGINEERING 

Interoperability  is  the  "ability  of  systems, 
units,  or  forces  to  provide  services  to  and 
accept  services  from  other  systems,  units,  or 
forces  and  to  use  the  services  so  exchanged 
to  enable  them  to  operate  effectively 
together  and  achieve  the  assigned 
mission"(JCS  Pub  1).  To  engineer  or  test  at 
the  Battle  Group/Battle  Force  level  in  a 
shore  based  environment  requires  that  real 
combat  system/BMC4I  hardware  and 
computer  programs  for  the  systems,  units, 
and  forces  be  connected  together  and 
operated  as  a  family-of- systems.  Distributed 
Engineering  is  the  application  of 
engineering  functions  and  activities  by 
connecting  "real"  hardware,  computer 
programs,  and  personnel  at  geographically 
dispersed  locations  throughout  the  country 
using  telecommunication  and  networking 
activities  (Task  Force  on  Combat  Systems 
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Interoperability  Report,  Vol.  I  of  II,  June 
1998).  Distributed  engineering  would 
permit  performing  secure  engineering 
functions  and  activities  through  the  sharing 
of  information,  databases,  and  analytical 
models  by  geographically  dispersed 
engineering  teams. 

Critical  elements  permitting  the  design  and 
establishment  of  a  Navy  Distributed 
Engineering  Plant  were: 

a.  Crisis  level  Navy  interoperability 
problems  resulting  in  non-deployable 
combatants, 

b.  Navy  combat  system  and  BMC4I 
facilities  with  real  hardware  and 
computer  programs, 

c.  Combat  system  and  C4I  community 
networking  via  Tactical  Data  Links 
using  telephone  lines, 

d.  DARPA  investment  in  Asynchronous 
Transfer  Mode  (ATM)  networking, 
FASTLANE  cryptography  technology, 
and  Distributed  Interactive  Simulation 
(DIS)  protocols, 

e.  Commercial  telecommunication 
Asynchronous  Transfer  Mode  networks, 
and 

f  FASTLANE  very  high  speed/low 
latency  encryption. 


A  crisis  was  created  when  the  Navy  could 
not  deploy,  as  combat  ready,  the  US S 
VICKSBURG  (CG69)  and  USS  HUE  CITY 
(CG66).  This  created  the  momentum 
necessary  to  move  Battle  Group/Battle 
Force  family-of-system  testing  ashore. 

The  Navy  had  established  a  number  of  In- 
Service  Engineering  Activities  (ISEAs), 
Software  Support  Activities  (SSAs),  combat 
system  integration  and  engineering 
activities,  and  training  activities  throughout 
the  United  States.  These  activities  contain 
real  hardware  and  computer  programs  for 
combat  systems,  BM/C4I  system,  and  data 
links  identical  to  that  deployed  or  being 
deployed  in  Battle  Group/Battle  Force. 
Some  of  these  activities  include:  NSWC, 
Port  Hueneme  Division  (PHD)  Integrated 
Combat  System  Tests  Facility  (ICSTF)  San 
Diego,  NSWC  Dahlgren  Division  AEGIS 
Computer  Center  (ACC),  Surface  Combat 
System  Center  (SCSC)  Wallops  Island, 
AEGIS  Training  and  Readiness  Center 
(ATRC),  NSWC,  PHD  Dam  Neck, 
SPAWAR  System  Center  (SSC)  San  Diego 
and  Charleston  System  Integration 
Environment  (SIE),  and  NAWC-AD  Pax 
River 

Fundamental  distributed  networking  and 


Figure  1 .  Fundamental  Distributed 
Network  Testing  circa  1995  -  1998 
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testing  directly  applicable  to  a  Navy 
Distributed  Engineering  Plant  had  been 
conducted  by  several  of  these  activities.  For 
example,  between  1995  and  1998  SCSC, 
Wallops  Island  and  Dam  Neck  conducted 
testing  with  Link  1 1  and  Link  16  land  lines 
using  CEC  and  fleet  assets,  see  Figure  1 . 

Additionally,  Navy  facilities  had 
demonstrated  the  capability  to  perform 
distributed  linking  of  ships,  aircraft,  land- 
based  test  sites,  and  simulations  using  the 
Gateway  Terminal  Emulator  (GTE),  AEGIS 
Broadcast  Network  (ABN)  devices  and 
telephone  lines.  The  testing  activity 
connected  ICSTF/SSC-SD,  ACC,  SCSC, 
and  PHD-DN  using  Gateway  Terminal 
Emulators  and  AEGIS  Broadcast  Network 
devices,  see  Figure  2.  The  C4I  community 
had  six  years  experience  using  Gateway 
Terminal  Emulator  connectivity.  Gateway 
Terminal  Emulator  devices  were  in  use  at  46 
Joint/NATO  facilities,  the  Joint 
Interoperability  Test  Center  (JITC),  and  in 
the  Ballistic  Missile  Defense  Organization's 
Theater  Missile  Defense  System  Exerciser 
(TMDSE). 


The  DARPA  Synthetic  Theater  of  War 
(STOW)  program  reduced  to  practice  and 
demonstrated  combined  use  of 
Asynchronous  Transfer  Mode  Networks, 
FASTLANE,  and  Distributed  Interactive 
Simulation  communication  protocols  in  a 
distributed  network. 

Asynchronous  Transfer  Mode  technology 
uses  small  (5.3  byte)  fixed  length  cells  to 
facilitate  highly  efficient  and  very  fast 
switching.  The  small  fixed  length  cells  can 
be  easily  multiplexed  to  allow  sharing  of  a 
common  communications  infrastructure  by 
different  classes  of  users.  The  Asynchronous 
Transfer  Mode  technology  further  allows  for 
implementation  of  Quality  of  Service  (QoS) 
to  ensure  the  highest  priority  users  get  the 
protection  needed,  and  service  on  demand  as 
bandwidth  and  other  needs  change. 
Asynchronous  Transfer  Mode  can  support 
very  high  levels  of  service  (hundreds  of 
megabits)  to  the  end  user  at  the  desktop.  In  a 
wide  area  network.  Asynchronous  Transfer 
Mode  can  effectively  support  shared 
backbones  at  gigabit  speeds.  The  KG75 
FASTLANE,  a  high  speed  Asynchronous 
Transfer  Mode  network  encryption  device. 


ICSTF/SSC-SD 


Figure  2.  Link  16  Distributed  Testing 
Architecture 
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introduced  in  1997,  allowed  a  transition 
from  static  bulk  encryption  point-to-point 
links  to  a  dynamic  network  centric 
environment.  The  FASTLANE  has  a  peak 
throughput  of  up  to  622  Mbps  and  latency 
through  the  encryption  device  of  more  than 
two  orders  of  magnitude  less  than  prior 
technology. 

DISTRIBUTED 
ENGINEERING  PLANT 
CONCEPT 

Conceptually  linking  together  Navy  Combat 
and  BMC4I  system  facilities  using  a  high 
performance  ATM  network  to  establish  a 
Distribute  Engineering  Plant  (DEP) 
capability  involves  several  main  components 
(Task  Force  on  Combat  Systems 
Interoperability  Report,  Vol.  I  and  II,  June 
1998).  Figure  3  illustrates  the  conceptual 
DEP. 


The  blue  boxes  in  the  middle  layer  are  the 
actual  hardware-in-the-loop  (HWIL) 
systems  which  represent  the  actual  Fleet 
combat  and  C4I  systems.  These  systems 
include  both  the  hardware  and  tactical 
computer  programs  of  the  Fleet 
configuration  to  the  greatest  extent  possible. 

The  eommon  environment  represented  by 
the  upper  cloud  provides  the  superset  of 
surface  units  and  friend  and  foe  aircraft 
[targets]  which  are  visible  to  all 
participating  combat  systems  and  their 
sensors.  The  cloud  is  essentially  the  ground 
truth  picture  that  all  combatants  interact  with 
from  their  own  perspective  and  capability. 
The  common  environment  uses  a  scenario 
generator  to  develop  the  time  dependent 
location  of  the  targets  and  Distributed 
Interactive  Simulation  (DIS)  protocols  for 
distributing  entity  states  to  the  stimulators. 

The  stimulators  and  drivers  are  existing 
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Figure  3.  Distributed  Engineering  Plant  Concept 
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Distributed  Interactive  Simulation 
compatible  program  approved  units.  They 
are  the  conduit  by  which  the  HWIL  combat 
systems  interact  with  the  common 
environment.  They  usually  emulate  the 
sensor  systems  to  some  extent  and  are 
able  to  interact  with  the  common 
environment  in  a  manner  similar  to  the  real 
sensor  system. 

The  tactical  communications  connectivity 
cloud  refers  to  the  requirement  to  connect 
the  combat  systems  via  the  tactical  links 
(Link  1 1,  Link  16,  Link  4A)  and  networks 
(CEC)  that  they  will  deploy  with  normally. 
These  network  connections  are  the  means  by 
which  the  tactical  systems  pass  their 
perception  of  the  ground  truth. 

The  data  extraction  pipeline  refers  to  the 
requirement  to  capture  and  share  for  analysis 
the  data  extracted  from  the  Hardware-in- 
the-Loop,  the  ground  truth  picture  of  the 
common  environment  and  the  tactical 
communications  nets/links. 


A  collaborative  engineering  system  is 
needed  for  performing  engineering, 
preparing  test  plans  and  procedures,  and 
analyzing  data  over  the  distributed  system. 

Finally,  data  analysis  tools  and  processes  are 
needed  to  enable  analysis  of  data  which  is 
collected  across  the  Distributed  Engineering 
Plant  and  to  compare  the  combat  system 
perceptions  with  ground  truth  of  the 
common  environment. 

Figure  4a  represents  the  Distributed 
Engineering  Plant  with  the  Asynchronous 
Transfer  Mode  network.  It  illustrates  how 
the  ground  truth  environment  and  scenario 
are  sent  over  the  ATM  network.  Distributed 
Interactive  Simulation  Protocol  Data  Units 
(PDUs)  provide  the  control  and  sensor 
tracking  information  to  the  remote  facilities 
via  the  tactical  data  links.  Each  platform 
forwards  reports  to  other  platforms  via 
tactical  data  links  [Link  1 1  &  Link  16]  over 
the  same  Asynchronous  Transfer  Mode 
network.  Combat  system  processed  results 
in  terms  of  link  messages  are  compared  to 
the  ground  truth  data  and  results  are 


SYSTEM  INTEGfUTED 
BIVIRONMBJT  (SPAWAR) 


analyzed  to  identify  problem  areas.  The 
Distributed  Engineering  Plant  provides  the 


Figure  4a.  Distributed  Engineering  Plant 
Functional  Chart 
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capability  to  replicate  the  Battle 
Group/Battle  Force  configurations  in  a  land 
based  repeatable  environment  that  is 
consistently  measurable.  Thus,  test  events 
are  easily  repeatable  under  strictly 
controlled  conditions.  Products  include  (1) 
engineering  quality  data,  (2)  validating  the 
Battle  Group  Tactical  Data  Link  network 
setup,  (3)  developing  workarounds  for 
identified  interoperability  problems,  (4) 
isolation  of  problems,  (5)  documentation  as 
Trouble  Reports  (TRs),  and  (6)  validating 
Fleet  Capability  &  Limitation  documents  for 
training  and  deployment. 

Figure  4b  decomposes  any  one  of  the  brown 
boxes  from  Figure  4a  and  shows  the 
transformation  of  a  typical  shipboard 
configuration  to  a  typical  distributed 
engineering  configuration.  The  radio.  Data 
Terminal  Set  (TDS)  and  KG40  have  been 
replaced  by  the  AEGIS  broadcast  network’s 
Link  Data  Distribution  Device  (LDDS)  and 
STU  III  encryption.  The  JTIDS  terminal  has 
been  replaced  by  the  Gateway  Terminal 
Emulator  with  radio  frequency  (RF) 


message  path  replaced  with  the 
Asynchronous  Transfer  Mode  network  path. 
The  radar  is  replaced  with  the  Program 
Executive  Office/Program  Manager 
approved  combat  system  stimulator  with  its 
sensor  input  replaced  by  Distributed 
Interactive  Simulation  entity  states  over  the 
Asynchronous  Transfer  Mode  Network.  The 
combat  system  hardware  and  tactical 
computer  programs  [C2P  &  TDS]  are 
unchanged. 


A  Distributed  Engineering  Plant  has  far 
more  potential  than  just  Battle  Group/Battle 
Force  testing.  It  can  be  used  to:  (1)  design 
and  develop  engineering  solutions  for  TRs 
for  currently  fielded  systems,  (2)  verify  that 
the  solutions  work  correctly  in  a  family-of- 
systems  environment,  (3)  engineer-in 
interoperability  for  systems  in  the  design 
and  development  phases  of  the  acquisition 
cycle,  and  (4)  as  risk  reduction  preparing  for 
Battle  Group/Battle  Force  level  Fleet 
Operational  Test  and  Evaluation  events. 


TYPICAL  DEP  CONFIGURATION 


Figure  4b.  Example  shipboard  combat  system 
configuration  transformation  to  distributed 
engineering  configuration 
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JOHN  F.  KENNEDY  BATTLE 
GROUP  (JFK  BG) 
DISTRIBUTED 
ENGINEERING  PLANT 
EXAMPLE 


Stand-up  of  the  Navy  Distributed 
Engineering  Plant  started  in  September  1998 
with  prototype-Plant  multi-site 
interoperability  testing  of  the  KENNEDY 
Battle  Group  beginning  in  January  1999. 

The  initial  Distributed  Engineering  Plant 
focus  has  been  on  the  Air  Defense  mission 


Figure  5a.  KENNEDY  Battle  Group 
Distributed  Engineering  Environr"''rt 


Implementation  (Simplified  Diagram) 


As  of  Dec.  22  98 


area.  Figures  5a  and  5b  illustrate  the 
connected  sites,  combatant  combinations  at 
the  sites,  simulation/  stimulation  Common 
Seenario  Control  Environment  (CSCE), 
Distributed  Sensor  Simulation  System 
(DS3),  AEGIS  Combat  System  Interface 
Simulation  (ACSIS),  and  link  operating 
environment.  The  JFK  Distributed 
Engineering  Plant  test  bed  consisted  of 
Naval  Surface  Warfare  Center  Dahlgren 
Division  (NSWC-DD),  AEGIS  Computing 
Center  (ACC),  AEGIS  Training  and 
Readiness  Center  (ATRC),  Surface  Combat 
System  Center  (SCSC)  Wallops  Island, 
SPAWAR  System  Center  San  Diego  (SSC- 
SD)  System  Integration  Facility  (SIF),  Naval 
Surface  Warfare  Center  (NSWC)  Port 
Hueneme  Division  (PHD)  ICSTF  San 
Diego,  and  NSWC  PHD  Dam  Neck  test 
facilities. 


To  support  Battle  Group  Interoperability 
Testing  an  environment  was  designed  that 
emulates  Battle  Group  operations  and 
composition  at  ashore  facilities.  Individual 
test  site  configurations  replicated  the  actual 
KENNEDY  Battle  Group  hardware  and 
tactical  computer  programs  in  the  loop.  A 
common  environment  used  existing 
Simulators/Stimulators  to  provide  all  sites 
with  a  shared  realistic  sensor  picture  using 
Distributed  Interactive  Simulation  protocol. 
The  participating  sites  were  interconnected 
via  an  Asynchronous  Transfer  Mode 
network  that  supports  the  Link  16  tactical 
data,  the  common  environment,  and  video 
teleconferencing  communications. 
Additionally,  the  Asynchronous  Transfer 
Mode  network  supports  all  voice  tester-to- 
tester  communications.  In  the  KENNEDY 
Battle  Group  prototype-Plant  the  Link  1 1 
information  was  passed  using  conventional 
telephone  lines  and  STU  III  cryptography. 
This  was  due  to  the  inability  of  converting 
AEGIS  broadcast  network  devices  to  work 
across  the  Asynchronous  Transfer  Mode 
network  and  meet  scheduled  test  start  dates. 

The  plant  network  was  validated  by 
conducting  “ping”  testing  through  the 


Asynchronous  Transfer  Mode  network  to  all 
Distributed  Engineering  Plant  nodes 
verifying  internet  protocol  assignments,  and 
conducting  end-to-end  wide  area  bandwidth 
analysis.  A  typical  east  coast  to  west  coast 
round  trip  Asynchronous  Transfer  Mode 
network  time  (Dahlgren,  Virginia  to  San 
Diego  California)  was  measured  to  be  63 
milliseconds.  Between  east  coast  sites 
(Dahlgren,  Virginia  and  Pax  River, 
Maryland)  that  time  was  measured  to  be  13 
milliseconds.  The  plant  SIM/STIM  was 
validated  by  verifying  that  each  site 
individually  was  Distributed  Interactive 
Simulation  capable.  Site  to  site  scenarios 
were  passed  using  Distributed  Interactive 
Simulation  Entity  State  Protocol  Data  Units 
until  a  full  up  operational  scenario 
verification  was  conducted  with  all  sites 
over  the  Asynchronous  Transfer  Mode 
network.  The  AEGIS  Broadcast  Network 
Link  1 1  sites  were  validated  out  using  Link 
1 1  message  protocols,  and  the  Gateway 
Terminal  Emulator/AEGIS  Broadcast 
Network  Link  1 6  sites  were  validated  using 
“ping”  checks  over  the  Asynchronous 
Transfer  Mode  network.  Full  Link  1 1/16 
open  and  closed  loop  tests  were  conducted. 
Lastly,  a  full  Distributed  Engineering  Plant 
dry  run  was  conducted  with  scenario 
execution  per  test  procedures  and  the  data 
collection  process  was  verified. 

Scenarios  were  developed  according  to  the 
test  procedures  that  provided: 

1 .  Light  to  medium  target  loading  with  a 
background  of  commercial  air  traffic  for 
tracking,  data  registration,  and 
identification  (ID)  testing, 

2.  Controlled  intercept  and  escort  of  enemy 
aircraft  with  friendly  aircraft  with 
variations  in  IFF  and  IFF  modes, 

3.  Light  to  medium  target  loading  in  a 
target  rich  data  link  environment  for 
tracking,  data  registration,  identification 
(ID)  testing,  multi-Tactical  Data 
Information  Link  (TADIL)  operations, 
and  air  control,  and 

4.  Medium  target  load  with  commercial  air 
traffic  for  tracking,  identification  (ID) 
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testing,  force  orders,  and  weapons 
coordination. 

The  scope  of  the  prototype-Plant  initial  tests 
and  KENNEDY  interoperability  testing 
(USS  John  F  Kennedy  (CV  67)  Battle  Force 
Interoperability  Test  Plan  and  Test 
Procedures;  NAVSEASYSCOM,  January 
1 999)  was  to; 

a.  Implement,  validate,  and  demonstrate  a 
land  based  distributed  Battle  Group 
capability. 

b.  Characterize  the  effectiveness  of 
installed  combat  systems 

c.  Assess  the  impact  of  baseline  upgrades 
and  program  problem  corrections,  and 

d.  Validate  tactics,  techniques,  and 
procedures  including  proposed 
workarounds  for  interoperability 
problems  for  inclusion  in  a  BG 
Capability  and  Limitation  document. 

The  test  configuration  for  KENNEDY  was 
as  shown  in  Table  1 . 

The  seasoned  test  director  for  this  operation 
made  the  following  observation:  “the 
Distributed  Engineering  Plant  reproduced, 
on  a  daily  basis  the  interoperability  issues 
that  plague  the  Navy  -  such  as  track  dualing, 
ID  contradictions,  track  blooming,  and 


inability  to  reliably  control  and  monitor 
force  engagements.  In  the  long  term,  the 
Distributed  Engineering  Plant  will  help 
provide  the  path  to  true  interoperability  as 
combat  systems  are  drastically  redesigned  or 
new  ones  developed.  In  the  near  term,  the 
Distributed  Engineering  Plant  will  validate 
methods  of  operating  with  the  current 
limitations  and  flaws.” 

The  Distributed  Engineering  Plant  provided 
a  controllable  repeatable  environment 
enabling  fault  isolation,  facilitating 
resolution  and  providing  the  engineering 
environment  for  verification  of  resolution. 
This  has  been  conclusively  demonstrated  in 
plant  operations  to  date.  For  example: 

(1)  Navy’s  LHD’s  were  reporting  a 

“jumping  Participating  Unit  (PU)  and 
track  picture”  for  over  a  year  prior  to 
Navy  Distributed  Engineering  Plant 
stand-up.  This  problem  could  not  be 
replicated  at  the  Integrated  Combat 
Systems  Test  Facility  (ICSTF)  in  San 
Diego  or  on  board  ship  using  the 
Combat  System  Test  Set  (CSTS). 
However,  this  anomaly  was  observed 
during  the  KENNEDY  Battle  Group- 
Navy  Distributed  Engineering  Plant 
Battle  Group  Integration  Testing  20 
January  -  28  February  1999.  Both  the 


Ship  Name 

"Hull 

Number 

Combat  System 

Software 

~C2P 

Software 

“CEP 

Software 

USS  John  F.  Kennedy 

CV57 

ACDS  BLK1  LvI  2.1.2 

M5R206B03 

CEC  B/L  2  7.06 

USS  Monterey 

AWS  3A.0.8.2 

M5R3.07A00 

N/A 

USS  Bataan 

lhd-5 

'ACDSBLKOLvTIO 

N7A 

NTS 

USS  Carney 

DDG-64 

AWS  5.0.Z5 

M4R4.04B04 

NTS 

USS  The  Sullivans 

DDG  68 

AWS  5.3.6.3 

M5R3.07A00 

N7A 

USS  McFaul 

DDG-74 

AWSSXeTS 

M5R3.07A00 

R77^^ 

USS  Spruance 

CDs  DD963/B6WV8R1O/0009A 

RTA 

N/A 

USS  Hancock 

DD-9d-| 

CDS  DD963/B6WV8R10/0009A 

RTS 

WA 

USS  Underwood 

FFG-36 

CDS  C4.0/L13/FFG7/003X 

HIA 

N7A 

USS  Taylor 

FFG-50 . 

CDS  C4.O/L13/FFG7/0O3X 

N/A 

NTS 

Table  1.  JFK  Test  Combat  System  and  Command 
Communication  Processor  (C2P)  Test 
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USS  UNDERWOOD  (FFG  36)  and 
USS  TAYLOR  (FFG  50)  Participating 
Unit  positions  jumped  over  800  miles 
from  their  correct  location  as  observed 
at  USS  BATAAN  (LHD  5).  [Their 
positions  were  correct  and  stable  as 
observed  on  USS  KENNEDY  (CV  67) 
and  USS  JOHN  HANCOCK  (DD  981)]. 
When  Ship  Gridlock  System/Automatic 
Correlation  (SGS/AC)  was  placed  in  the 
“transparent  mode”,  Participating  Unit 
position  would  remain  correct.  Logic 
analyzer  data  extraction  at  the  Link  Data 
Distribution  Device  (LDDS  1 1)  -  Ship 
Gridlock  System/Automatic  Correlation 
interface  indicated  a  single  Ml  being 
transmitted  from  the  USS 
UNDERWOOD  (FFG  36)  as  the  only 
deviation  from  OPSPEC  411.  Extensive 
discussions  with  Ship  Gridlock  System 
personnel  indicated  potential 
misunderstanding  of  data  values  for 
Advance  Combat  Direction  System 
(ACDS)  enabling  “Extended  Range”.  A 
follow-on  meeting  at  NSWC,  Dam 
Neck,  the  week  of  15  February  1999, 
with  Advance  Combat  Direction  System 
and  Ship  Gridlock  System  personnel  did 
not  produce  exact  problem  isolation,  but 
Dam  Neck  did  produce  a  patch  for  the 
singular  Ml  anomaly.  This  patch  was 
inserted  and  the  Participating  Unit 
jumping  problem  ceased.  The  patch  was 
subsequently  inserted  and  removed  to 
ensure  Participating  Unit  jumping 
followed  the  non-patch  configuration. 
Navy  Distributed  Engineering  Plant  test 
personnel  recommended  further  system 
engineering  discussions  and 
investigation  by  Program  Executive 
Office  personnel  to  ensure  a  complete 
understanding  of  the  problem  and  the 
“Extended  Range”  enabling  sequence. 

(2)  The  FFG-7  Class  Link- 16  drop  track 
messages  was  a  classic  example  of  a 
spurious  Battle  Group/Battle  Force 
interoperability  problem  observed  by  the 
fleet  but  not  understood  sufficiently  by 
the  technical  community  to  isolate  the 
root  cause.  It  had  not  become  a  high 


profile  issue  because  standard  OPTASK 
guidance  restricted  the  FFG  to  report- 
by-exception.  Repeatable,  controlled 
tests  in  the  Navy  Distributed 
Engineering  Plant  revealed  that  the  FFG 
software  had  been  coded  to  an  outdated 
version  of  MIL-STD-601 1/OS41 1 . 

NAVY  DISTRIBUTED 
ENGINEERING  PLANT 
ACTIVITIES 

Navy’s  Distributed  Engineering  Plant  has 
been  a  resounding  success  at  moving  Battle 
Group/Battle  Force  testing  ashore.  In  CY99, 
‘Plant’  employment  encompassed  the 
spectrum  of  acquisition  activities  —  from 
Test  and  Evaluation  of  fielded  systems  to 
system  and  element  tests  of  Baseline 
Upgrades  and  new  programs  in  a  multi¬ 
system  environment. 

Battle  Group  Integration  Tests 

-  KENNEDY  Battle  Group 

-  EISENHOWER  Battle 
Group 

-  WASHINGTON  Battle 
Group 

-  LINCOLN-TRUMAN 
Battle  Groups 

Battle  Group  Y2K  Tests 

-  KENNEDY  Battle  Group 

-  CONSTELLATION  Battle 
Group 

-  EISENHOWER  Battle 
Group 

STENNIS  Battle  Group 

-  WASHINGTON  Battle 
Group 

System/Element  Tests 
AEGIS  Baseline  5.3.7 
Cooperative  Engagement 
Capability  (CEC)  IV&V 
(In  progress) 

CEC  Operational 
Evaluation  (OPEVAL) 

-  Satellite  TADIL  J  (S 
TADIL  J) 
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WHAT  IS  A  JOINT 
DISTRIBUTED 
ENGINEERING  PLANT? 

It  was  envisioned  that  the  Joint  Distributed 
Engineering  Plant,  like  the  Navy  Distributed 
Engineering  Plant,  would  be  an  organized 
assembly  of  existing  Service/  Joint  combat 
system  engineering  sites  (including  Design 
and  Development  Activities,  Software 
Support  Activities,  Test  and  Evaluation 
Facilities,  and  Training  Centers)  disparately 
located  around  the  country,  interconnected 
by  emulated  tactical  data  links,  and 
stimulated  in  a  prescribed  and  predictable 
manner.  Some  of  the  important  attributes  of 
the  sites  that  would  be  part  of  a  Joint 
Distributed  Engineering  Plant  are: 


They  have  at  least  an  initial 
focus  on  Joint  Air  Defense. 

They  contain  tactical  hardware 
and  computer  programs,  and  are 
not  large-scale  simulations  of 
actual  systems. 

They  contain,  in  aggregate,  at 
least  one  of  each  of  the  relevant 
or  critical  systems  to  the  warfare 
mission  of  focus  (Joint 
Integrated  Air  Defense,  in  the 
near  term). 

Functionally  speaking,  a  fundamental 
purpose  of  a  Joint  Distributed  Engineering 
Plant  would  be  to  provide  an  environment 
suitable  to  conduct  theater  level  systems  and 
system-of-systems  interoperability  tests  and 
experiments.  These  would  be  conducted  to 
determine  that  systems  about  to  be  fielded  as 


Joint  Distributed  Engineering  ‘Plant’ 


Sensor  /  Weapons  SIM/STM  Connectivity  (Ground  Truth) 


Voice  Admin  '  ,  Network  Test  D^aTools  Doc 

VTC  Tools  Scheduler  Mgmt  Planning  Repository  Analysis  Mgmt 


Shared  Process/ 
Apps  Workflow 


Visual 


Figure  6.  Joint  Distributed  Engineering  Plant 
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a  unit  or  set  of  units  could  function  together 
to  provide  the  operational  commander  a 
capability  as  a  system  rather  than  a  set  of 
components  that  do  not  interact  well. 

Key  attributes  of  the  necessary  environment 
are  repeatability  and  suitable  (given  that  the 
Distributed  Engineering  Plant  is  not  in  the 
Battlefield)  replication.  Even  if  the  time  and 
equipment  were  available  to  conduct  the 
necessary  tests  or  experiments  in  the  field,  it 
would  not  be  possible  to  repeatedly 
duplicate  the  conditions  in  a  controlled 
fashion  to  fault  isolate,  determine  resolution, 
and  validate  the  value  of  design  or  other 
changes  made  to  fix  problems. 

The  concept  of  linking  together  a  Joint 
Distributed  Engineering  Plant,  similar  to  the 
Navy  Distributed  Engineering  Plant  shown 
in  Figure  3,  would  involve  the  establishment 
of  several  components,  as  shown  in  Figure 
6. 


WHY  A  JOINT  DISTRIBUTED 
ENGINEERING  PLANT 
(JOINT  DEP)? 

Real-world  operations,  exercises,  and 
evaluations,  e.  g.,  CENTCOM  TADIL 
Improvement  Program  (1997,  1998), 
Adriatic  Operations  (1999),  U.S.  Forces 
Korea  (1999),  Joint  Air  Defense 
Organization/Operation  (JADO)/Joint 
Engagement  Zone  (JEZ),  and  All  Service 
Combat  Identification  Evaluation  Team 
(ASCIET)  evaluations  (1992  —  present), 
continue  to  highlight  joint  warfighting 
capability  shortfalls: 

•  IFF/SIF  conflicts 

•  Erratic  tracking 

•  Dual/multiple  track  designations 

•  Misidentification/Track  ID  conflicts 

•  Reporting  responsibility  (R2)  conflicts 

•  Frequent  track  number  changes  and 
swaps 

•  Reliance  on  voice  de-confliction 

•  Operator  overload 


In  the  aggregate,  these  shortfalls  make  the 
Joint  Theater  Air  and  Missile  Defense 
(JTAMD)  family-of-systems  ‘Not 
Interoperable’.  Some  related  causes  are; 

•  Stovepipe  systems  not  compliant  with 
technical  architecture  framework  for 
information  management  and  JTA. 
(source:  USJFCOM  Integrated  Priority 
List  (IPL)) 

•  Automated  identification  processing 
differences 

IFF/SIF  association 
Multi-Source  Integration 
(source:  USJFCOM  IPL/  JTAMD 
Master  Plan  98B) 

•  Poor  tracking  performance  and 
inaccurate  assignment  of  Track  Quality 
(TQ),  resulting  in  improper 
assumption/retention  of  Reporting 
Responsibility  (R2)  (source: 

OASD/C3I) 

•  Correlation/de-correlation  algorithm 
differences  (source:  OASD  C3I  & 
JTAMD  MP  98B) 

•  JTAMD  Family  of  Systems  use  different 
correlation  algorithms  to  evaluate 
identical  tracks,  (source:  ASCIET  97 
Results) 

•  Time  latency  and  poor  correlation 
contributes  to  multiple  tracks  on  single 
targets,  (source:  JTAMD  MP  98B) 

From  this  abbreviated  listing  it  is  clear  that 
Joint  interoperability  problems,  as  with 
Navy,  are  not  just  interface  issues  resulting 
from  incorrect  implementation  or 
interpretation  of  system  interface 
specifications,  although  those  types  of  errors 
do  exacerbate  the  problems.  They  are  more 
fundamental  and  complex.  Again,  there  is 
missing  Joint  force  level  system  engineering 
and  analysis  work  associated  with 
identifying  and  testing  the  performance 
characteristics  that  family-of-systems  must 
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have  to  support  when  constructing  a  Single 
Integrated  Air  Picture  (SIAP). 

To  make  progress  toward  significant 
reduction  or  elimination  of  the  issues 
currently  plaguing  the  Joint  air  picture, 
experiments  and  tests  must  be  repeatable 
and  controllable.  Effects  and  interactions 
that  were  not  anticipated  are  very  likely, 
leading  to  the  need  to  rework  the  data 
collection  and  some  test  procedures  to 
assure  an  adequate  understanding  of  cause 
and  effect.  This  repeatable  and  controllable 
environment  cannot  be  obtained  using  live 
targets  and  operational  forces.  Similarity  is 
all  that  can  be  expected,  and  that  is  not 
enough  to  support  the  required  engineering. 

Interoperability  testing  to  date  for  Joint 
Integrated  Air  Defense  has  predominately 
been  focused  on  message  fields  and  data 
link  Operational  Specification  (OPSPEC) 
compliance.  These  are  certainly  important, 
but  are  not  sufficient  to  give  confidence  that 
the  combat  systems,  when  operated  together, 
will  perform  as  a  whole.  In  Joint  Integrated 
Air  Defense  the  air  picture  issues  are  located 
in  the  code  of  the  software  in  the  combat 
systems,  not  the  data  links;  for  this  reason  a 
broader  view  of  interoperability  is  required. 

A  Joint  Distributed  Engineering  Plant  would 
provide,  for  the  first  time,  the  environment 
to  enable  disciplined  systems  engineering 


and  testing  at  the  Joint  Force-level. 

From  a  systems  engineering  perspective, 
future  platform  and  system  tradeoffs  must  be 
made  in  the  context  of  the  aggregation  of 
platforms  in  a  Joint  Force  system.  From  a 
testing  perspective,  a  Joint  Distributed 
Engineering  Plant  would  provide  a 
repeatable,  controlled  environment  for 
evaluation  of  Joint  Force-level 
interoperability  problems  -  -  enabling  the 
engineer  to  determine  ‘why’,  vice  just 
replicating  interoperability  problems  -  -  and 
recommend  ‘workarounds’  and  ‘fixes’. 

Lastly,  a  Joint  Distributed  Engineering  Plant 
would  enable  Joint  Forces  to  validate 
operational  Tactics,  Techniques  and 
Procedures  prior  to  deployment.  (Joint 
Engineering  Task  Force  Final  Report,  Vol.  I 
-  Ill,  JTAMD,  November  1999) 


THE  BUILDING  BLOCKS 

One  of  the  building  blocks  of  the  Joint 
Distributed  Engineering  Plant  would  be,  of 
course,  the  Navy’s  Distributed  Engineering 
Plant.  But  there  are  a  number  of  other 
Service  and  Joint  initiatives  from  which  to 
leverage. 

The  Theater  Missile  Defense  System 
Exerciser  (TMDSE),  shown  in  Figure  7,  is  a 


Figure  7.  Theater  Ballistic  Missile  Defense 
System  Exerciser  (TMDSE) 
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Ballistic  Missile  Defense  Organization 
(BMDO)-developed  high-fidelity  test  tool. 
Theater  Missile  Defense  System  Exerciser 
uses  a  dedicated  T-1  point-to-point 
communications  architecture,  in  a  star 
topology,  to  net  together  existing  hardware 
and  simulations.  Connectivity  is  provided  at 
stand-alone  Design  and  Development 
Activities,  Software  Support  Activities,  Test 
and  Evaluation  Facilities,  and  Training 
Centers  to  identify  Joint  Theater  Air  and 
Missile  Defense  interoperability  problems  at 
the  JTAMD  family-of-systems  level.  The 
Joint  National  Test  Facility  (JNTF),  at 
Schriever  AFB,  CO,  is  normally  the 
operational  test  exerciser  controller.  The 
following  Joint  and  Services  facilities  are 
netted  together: 

Army 

Huntsville  (Redstone  Arsenal),  AL  for 
PATRIOT  and  THAAD  elements 

Azusa,  CA  (Aerojet)  for  Joint  Tactical 
Ground  Station  (JTAGS). 

Fort  Bliss,  TX  for  operational  PATRIOT 
and  THAAD  elements. 

Navy 

NSWC,  Dahlgren,  VA  for  AEGIS  Weapon 


System  (AWS). 

USMC 

Syracuse,  NY,  US  Marine  Corps  TBMD 
elements  including  the  AN/TPS-59  Radar 
Environmental  Simulator  and  the  Air 
Defense  Communications  Platform  (ADCP). 

Air  Force 

Schiever  AFB,  CO  Aerospace  Fusion  Center 
(AFC) 

Kirtland  AFB,  NM  (Theater  Air  Command 
and  Control  Facility)  Control  and  Reporting 
Center  (CRC)  and  AWACS  (E3  SIM). 

Joint 

Joint  National  Test  Facility,  Schiever  AFB 

Theater  Missile  Defense  System  Exerciser  is 
used  early  in  the  acquisition  cycle  for  design 
and  development  and  is  of  a  higher  fidelity 
than  Navy  Distributed  Engineering  Plant. 
Theater  Missile  Defense  System  Exerciser 
provides  realistic  quantities  and  types  of 
Theater  Ballistic  Missiles  (TBMs)  and  Air 
Breathing  Targets  (ABTs)  threats  and  man¬ 
made  and  natural  environments.  Threat 
stimuli  (e.g..  Radar  Cross  Section  (RCS), 
Infra-Red  (IR),  etc.)  is  injected  into  Service 
tactical  sensor's  digital  data  processors  in 


•ti  &  Sens  or  simulation 
#T1  No  Sensor  Simulation 


Figure  8.  Joint  Interoperability  Test  Center 
(JITC) 
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real-time.  Update  rates  and  timing  match 
tactical  interfaces.  Integration  and 
interoperability  are  assessed  when  operators 
and  systems  respond  to  the  threat 
environment.  Threats  and  defensive  systems 
interact  dynamically  through  their  BM/C4I 
as  they  would  in  a  real  deployment  situation 
using  only  an  emulated  Joint  Data  Network 
(Link  16). 

The  Joint  Interoperability  Test  Center 
(JITC)  at  Fort  Huachuca,  AZ,  as  shown  in 
Figure  8,  uses  the  Joint  Tactical  Data  Link 
Laboratory  (T1  and  Integrated  Services 
Digital  Network  (ISDN))-based  network 
with  sensor  simulation  and  secure 
tactical/voice  communications  to  conduct 
interoperability  certification  testing  as 
shown  in  Figure  8. 

The  network  is  primarily  used  for  Joint 
Tactical  Communications  certification. 
Communications  is  accomplished  via 
dedicated  T1  links.  TADIL  J  is  distributed 
using  the  Gateway  Terminal  Emulator 
(GTE)  tool.  The  Joint  Interoperability  Test 
Center  operates  the  Central  Test  Facility 
(CTF)  at  Ft.  Huachuca.  Remote  Test 
Facilities  (RTFs)  are  located  at  various 
support  centers,  including  a  new  Remote 
Test  Facility  in  Iceland  for  the  Icelandic  Air 
Defense  System  and  a  JSTARS  SSF  RTF  to 
be  located  on  Robins  AFB  in  Georgia. 

There  are  a  number  of  existing  Department 
of  Defense  network  resources  with 
connectivity  at  several  of  the  potential  Joint 
Distributed  Engineering  Plant  sites  that  offer 
the  features  and  characteristics  required  for 
implementation  of  the  underlying  network 
support  needed  for  Joint  Distributed 
Engineering  Plant  tools  and  functions.  The 
Defense  Research  and  Engineering  Network 
(DREN),  the  Navy  Distributed  Engineering 
Plant,  Leading  Edge  Services  (LES),  and 
Federated  Battle  Labs  (FBL)  are  all 
Asynchronous  Transfer  Mode-based  Wide 
Area  Networks  with  Internet  Protocol  (IP) 
and  Asynchronous  Transfer  Mode  services 
at  the  individual  sites.  Sites  in  these  user 
communities  can  be  bridged  from  one 
network  or  service  to  another.  Extensions  to 


or  shared  use  of  these  existing  services 
potentially  could  meet  Joint  Distributed 
Engineering  Plant  needs.  Negotiations  for 
shared  use  or  bridging  of  any  of  the 
networks  indicated,  though  technically 
feasible,  would  depend  on  existing  loading, 
service  models  and  charter.  The  Navy 
Distributed  Engineering  Plant  successfully 
used  this  sharing  model  and  operates  on  a 
combination  of  Leading  Edge  Services 
(primary  service).  Defense  Research  and 
Engineering  Network  (shared  at  NSWC, 
Dahlgren  and  NAWC,  Pax  River),  and 
dedicated  extensions  (Surface  Combat 
Systems  Center,  Wallops  Island).  Where  it 
makes  sense,  and  where  the  Joint 
Distributed  Engineering  Plant  can  get 
agreement  across  communities,  the  Joint 
Distributed  Engineering  Plant  could  employ 
a  combination  of  Leading  Edge  Services  and 
Defense  Research  and  Engineering  Network 
or  other  services  using  the  model  that  is 
working  for  the  Navy  Distributed 
Engineering  Plant  today. 

CONCLUSION 

Distributed  Engineering  at  the  Battle 
Group/Battle  Force  and  family-of-systems 
level  for  certification  testing,  development, 
and  risk  reduction  has  been  demonstrated 
using  advanced  Asynchronous  Transfer 
Mode  networking  technology  and 
FASTLANE  encryption  devices.  The  Navy 
Distributed  Engineering  Plant,  using  real 
hardware  and  computer  programs,  is 
addressing  interoperability  issues  through  a 
disciplined  engineering  process.  The  current 
Distributed  Engineering  Plant  functions  with 
“perfect”  connectivity,  open  ocean  without 
land  masking  effects,  and  without  weather 
or  environmental  effects.  A  challenge  will 
be  to  add  these  effects  into  the  Distributed 
Engineering  Plant  as  well  as  developing  the 
capability  for  the  Distributed  Engineering 
Plant  to  be  operated  in  conjunction  with  real 
fleet  assets. 

Since  we  fight  jointly,  we  must  engineer 
interoperability  jointly.  The  foundation 
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building  blocks  are  in  place  and  the  design 
for  establishing  a  Joint  Distributed 
Engineering  Plant  has  been  developed  by  the 
Joint  Engineering  Task  Force.  There  will  be 
many  challenges  to  putting  a  Joint 
Distributed  Engineering  Plant  in  place.  The 
greatest  challenges  are  not  technical.  They 
are  bringing  about  cultural  change, 
scheduling  the  engineering  sites,  and 
availability  of  talented  engineering  people. 
The  warfighting  pay-off  of  a  Joint 
Distributed  Engineering  Plant  will  be  great. 
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